NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/hardware-part1/2914

Text File | 1996-08-05 | 8.6 KB | 168 lines

Newsgroups: comp.sys.amiga.hardware
Path: news.kei.com!ub!dsinc!scala!news
From: [e-mail] (Dave Haynie)
Subject: Re: A3000 SCSI
Sender: [e-mail] (Usenet administrator)
Message-ID: <[e-mail]>
Date: Mon, 29 Jan 1996 17:34:40 GMT
Reply-To: [e-mail] (Dave Haynie)
References: <4crkgh$[e-mail]> <4djffa$[e-mail]> <4dlre0$[e-mail]> <4e0amr$[e-mail]> <4e0jru$[e-mail]> <4edjsc$[e-mail]> <4egdq5$[e-mail]>
Nntp-Posting-Host: gator
Organization: Scala Computer Television, US Research Center

In <4egdq5$[e-mail]>, Jeff Grimmett <[e-mail]> writes:
>[e-mail] (Warren Block) wrote:

>>: >Unless you have two controllers, you only have one SCSI bus, and the SCSI
>>: >spec is very clear on termination and the other rules (a couple of which
>>: >C= broke on the A3000).

The A3000 originally followed the SCSI termination rule: one set of
terminators at each end of the bus. However, this had the unfortunate
consequence that anyone adding an external drive would have to open up
the A3000, dig all the way to the motherboard, under the drive
platform, and pull out termination packs. Since that was undesirable,
we decided to go with one set, on the internal drive, and a short
cable. While this does stretch the spec, not that much: it always
works with the internal drive (something C= could guarantee in
manufacturing) and it always works when you add an external drive
(then you're SCSI-correct, as long as your external SCSI chain is
terminated).

Do realize that the use of SCSI in personal computers has come a long
way since then. Back in 1989, when most of the A3000 was designed,
there was no such thing as a commonly available active terminator, so
some of the better schemes, such as the termination switch I used on
the A4091, or even the termination-detect schemes some cards use in
conjunction with active terminators, weren't an option back then.

>>No, C= chose to do a couple of things wrong, and the users are the ones
>>who had to put up with it.  As usual.  To be fair, there may not have
>>been any conscious choice involved; things like the DB25 connector may
>>just have been "the way you do it" at that time.

The only thing "wrong" Commodore did, by choice, was the termination,
which in fact was designed as a benefit to users. There were some
issues with the SCSI terminal power diode being backwards for some
time, and the wrong type of diode. This was the result of our SCSI
expert leaving before the A3000 was done -- no one else was in a
position to know the details to that level.

The DB25 connector was the industry standard for small connectors,
although not part of the SCSI specs. SCSI at the time (this was
SCSI-1, after all) called for the Centronics-style 50 pin connector,
which was too large for a computer like the A3000. Apple had
introduced the 25-pin connector many years before, and it was
supported everywhere (on the A2090 and A2091 as welll; it had been
around at Commodore for awhile too). Since the 50 pin small form
SCSI-2 connector hadn't been an option, we with the de-facto standard,
as is usually your best bet in the computer business.

>CBM, when they found of the noncompliancies of thier design, had a few
>options open.

There was really nothing Commodore needed to do. The diode problem was
a trivial thing to fix, and only affected a small number of
boards. Problems in the Western Digital chip were addressed as they
were discovered, the real problem was the way Western Digital did that
part in the first place -- things changed without warning, bugs were
not reported to customers in a timely fashion, etc. SCSI software was
updated several times to accomodate the WD problems.

This was one big reason that, when I had a SCSI board to designed, I
dumed Western Digital like yesterday's bad news. Well, that and the
fact that the NCR 53C7xx chips had become the hot SCSI chip on
workstations, and I always figured Amigas should aim for the same
level of performance when possible.

>THAT is the reality we have to deal with.  The 3000 does NOT comply 100%
>with SCSI specs.  It comes close.  DAMNED close.  It is, for my money,
>one of the most compliant controllers for the Amiga market, with the 2091
>edging it out.

How? The A2091 is in all ways the 16-bit version of the A3000
controller. It has much the same termination and termpower diode
issues, the same 25-pin connector, and the same SCSI chip (well,
actually, it has to contend with both 33C93s and 33C93As, which is why
many A2091s lock up in reselection; in going to the A, code broke
without warning).

>Sure, 50-pins connectors are better from MANY viewpoints, but the things
>are EXPENSIVE compared to even top quality DB25 to 50-pin cables.

As I said, everyone used the Apple standard, even it wasn't in the
SCSI spec. So these cables are made in large quantities, and they're
cheap. The first place I saw the 50 pin SCSI-2 cable was on a Sun
Sparcstation. Even price Sparcstation add-ons?

>Ever price one of the high-density 50 pin cables?  I can get a DB25 type for
>$15, very good quality build.  The same company also sells a high-density
>cable.  For SIXTY fraggin' dollars.

I bought my last one for about $20, it works fine. But that was last
year; in the early 90s, these would have run you big bucks.

>It's like saying that a technical bulletin issued by Ford applies to
>Audis.

I don't the technical bulletin you're referring to, but unless Ford is
building Audis based on last year's Ford design, your analogy doesn't
apply. The A3000's original SCSI designed was based directly on the
A2091 design. If you get the Rev 4 DMAC, you have a from-scratch new
design there, with of course a more recent version of the same SCSI
chip Commodore used since the A2090.

>>Huh?  In what way is the A3000 SCSI non-standard, other than a minor flaw
>>in the way it is documented?  Please be specific.

>Well, since you won't accept the notion that at least early A3000
>motherboards had a problem with SCSI bus impendence, and thus requiring
>non-standard termination configurations, I sense a trap.

Don't know what you're talking abou there. There was never a problem
with SCSI bus impedence, unless this is something in the WD chip,
which we never had control over. The termination issues for the
motherboard were as I described, nothing more, nothing less.

>While it claims SCSI-II command
>compliance, you can not enable and disable synchronous transfers on a
>drive by drive basis.  You can only enable and disable synchronous
>transfers globally, for all drives or none of them.  This was openly
>acknowledge in both technical bulletin AND in developer documentation.

The issue of synchronous NEGOTIATION is global; you can specific if
the A3000 will negotiate for synchronous transfers, or not, and that's
global. I don't know what the SCSI-2 spec said back when the A3000 was
in progress, or what it said when finalized, on this issue. I do know
that many SCSI-2 host adaptors on the market, from many vendors, do
not offer individual controls over whether synchronous mode is
negotiated or not. The A3000 does individually negotiate for
synchronous transfers -- the point of being able to disable this,
individually or globally, is to allow support of non-SCSI-2 compliant
devices that get confused by the negotiation process.

>OK, throw a WD chip, some SCSI driver chips, some resistors, and whatever
>else you think would be appropriate into a cardboard box, close the lid,
>and shake vigorously.  Have you now ended up with a standard SCSI
>controller?  Let me know if this works, I always wanted to get rich.

While not quite that simple, the point is a valid one -- the SCSI chip
you use is primarily responsible for delivering a compliant SCSI
bus. The system designer has little control over the nature of the bus
itself -- termination, T.P., connector styles, and maybe additional
buffering (for differential SCSI) are about your only options. The
chips are involved in quite a bit of the SCSI protcol
implementation. Sure, there's a software component, but the success of
that is largely based on the SCSI chip behaving as specified by its
vendor, with the possible addition of hacks that get around places
where the docs and your SCSI analyzer disagree on some points. As SCSI
chips have become more sophisticated, the software's ability to alter
the protocol is diminished as well.

Dave Haynie          | ex-Commodore Engineering |   for DiskSalv 3 &
Sr. Systems Engineer |  Hardwired Media Company | "The Deathbed Vigil"
Scala Inc., US R&D   |    Ki No Kawa Aikido     |     [e-mail]

         "Feeling ... Pretty ... Psyched" -R.E.M.